src/routes/blog/post/how-to-leverage-dynamic-api-keys-for-better-security/+page.markdoc (1)

84-84: Use “row in a table” for precision and consistency with Tables terminology

“Row in the database” is slightly imprecise post-migration. Suggest “row in a table” to match the rest of the PR and current TablesDB wording.

-**4. Deploying and testing the function:** [Deploy your function](https://appwrite.io/docs/products/functions/functions) through the Appwrite console or the Appwrite CLI. Test the function by calling its endpoint and verifying that it performs the intended operations, such as creating a new row in the database.
+**4. Deploying and testing the function:** [Deploy your function](https://appwrite.io/docs/products/functions/functions) through the Appwrite console or the Appwrite CLI. Test the function by calling its endpoint and verifying that it performs the intended operations, such as creating a new row in a table.

src/routes/blog/post/product-update-jan-2025/+page.markdoc (1)

80-80: Capitalize “GitHub”.

Brand capitalization.

-Plus, we resolved Github identity conflicts to ensure smooth functionality.
+Plus, we resolved GitHub identity conflicts to ensure smooth functionality.

src/routes/blog/post/deploy-a-pdf-generation-service-with-appwrite-functions/+page.markdoc (1)

54-56: Tighten Tables terminology and auth guidance for consistency

Recommend explicitly naming Tables/TablesDB and clarifying the auth check to reference a userId column or row.$permissions for consistency with the broader migration.

Apply this minimal copy update:

-2. Get the order row from your Appwrite database, or external data source. Unsure about this? View code recipes on the **[Appwrite Function Docs](https://appwrite.io/docs/functions).**
-3. If necessary, use the order row to ensure the user has permission to see the order. For example, compare the `x-appwrite-user-id` header with the row user ID.
-4. Change the function to populate the PDF template with the real order row.
+2. Get the order row from Appwrite Tables (TablesDB) or your external data source. Unsure about this? See code recipes in the **[Appwrite Function Docs](https://appwrite.io/docs/functions).**
+3. Authorize access using the order row—for example, compare the `x-appwrite-user-id` header with a `userId` column on the row, or enforce via `row.$permissions`.
+4. Change the function to populate the PDF template with the real order row data.

src/routes/blog/post/open-source-firebase-alternative/+page.markdoc (1)

133-133: Nit: Double period after “HTTPS.”

Minor punctuation fix.

-- Each platform automatically provisions SSL certificates, ensuring that all content is served securely over HTTPS..
+- Each platform automatically provisions SSL certificates, ensuring that all content is served securely over HTTPS.

src/routes/blog/post/product-update-december-2024/+page.markdoc (4)

35-35: Minor heading grammar tweak.

Use “An” for natural phrasing.

-## MFA - Extra layer of security
+## MFA - An extra layer of security

---

41-41: Sentence case for “integrations”.

Keeps style consistent with the rest of the post.

-In May, we announced multiple AI Integrations to help developers build AI apps. With pre-built functions and an enhanced knowledge base, you can easily add features like natural language processing (NLP), image analysis, and audio processing to your projects.
+In May, we announced multiple AI integrations to help developers build AI apps. With pre-built functions and an enhanced knowledge base, you can easily add features like natural language processing (NLP), image analysis, and audio processing to your projects.

---

49-49: Tighten CLI copy; clarify “table data” and data flow.

“Between Appwrite and your CLI” is awkward; also explicitly say “data in existing tables.”

-No more overwriting or deleting existing table data during deployments. With the new Appwrite CLI, you can test functions locally and push or pull data between Appwrite and your CLI seamlessly without affecting existing data.
+No more overwriting or deleting data in existing tables during deployments. With the new Appwrite CLI, you can test functions locally and seamlessly push or pull data between your local environment and Appwrite without affecting existing data.

Please confirm this statement matches current CLI behavior for Tables (i.e., schema deploys don’t touch existing rows).

---

61-61: Role names: format consistently and verify exact labels.

Use code formatting for literal role names and confirm “Billing” is the exact Console label.

-In September, we launched the much-requested [Roles](https://appwrite.io/blog/post/announcing-roles-for-enhanced-collaboration-and-security) feature, making it easy for larger teams to manage access. Alongside the "Owner" role, new options include Developer, Editor, Analyst, and Billing.
+In September, we launched the much-requested [Roles](https://appwrite.io/blog/post/announcing-roles-for-enhanced-collaboration-and-security) feature, making it easy for larger teams to manage access. Alongside the `Owner` role, new options include `Developer`, `Editor`, `Analyst`, and `Billing`.

src/routes/blog/post/cors-error/+page.markdoc (3)

65-66: Use Tables API terminology and broaden IDs that can trigger CORS

Since Tables listRows requires databaseId/tableId, typos in any of these IDs (not just projectId) can yield 4xx responses and surface as CORS errors. Recommend clarifying.

-This one happens because of an improperly configured request, such as a typo when specifying a project ID. For example, when using the `listRows` method,
-if the project ID is set incorrectly when the client is initialized, you will receive a CORS error.
+This one happens because of an improperly configured request, such as a typo in your projectId, databaseId, or tableId. For example, when using the Tables API’s `listRows` method,
+if any of these IDs (or the projectId used when the client is initialized) is incorrect, you will receive a CORS error.

---

69-69: Use standard 4xx notation instead of 40X

Minor wording tweak for accuracy/consistency.

-The request returns a `40X` response, so the entire CORS check fails.
+The request returns a `4xx` response, so the entire CORS check fails.

---

24-24: Grammar nit: pluralize “request”

Small copy edit to improve readability.

-Site A, our server sitting at `myapi.com` won't allow request coming from site B, which is our client app sitting at `myfrontend.com`.
+Site A, our server sitting at `myapi.com`, won't allow requests coming from site B, which is our client app sitting at `myfrontend.com`.

src/routes/blog/post/open-source-vercel-alternative/+page.markdoc (3)

49-49: Grammar: remove superfluous comma after “although”.

-There's no manual UI deployment support, although, there’s a CLI option.
+There's no manual UI deployment support, although there’s a CLI option.

---

58-58: Typo: “CLi” → “CLI”.

-...deploy without needing Git or the CLi.
+...deploy without needing Git or the CLI.

---

134-134: Use product-canonical “dynamic API key” terminology
Replace the phrasing to match Appwrite’s official docs and clarify automatic injection:

-Appwrite also provides a **dynamic API key automatically**, scoped and injected for both the build process and runtime (for SSR). This makes it easier to create or configure tables at build time, or securely perform server-to-server operations during SSR.
+Appwrite automatically generates and injects a dynamic API key (aka ephemeral API key) for both build-time and SSR runtime. This lets you provision or configure tables during builds and securely perform server-to-server operations in SSR.

src/routes/blog/post/serverless-functions-best-practices/+page.markdoc (3)

134-134: Terminology consistency: “Databases” → “Tables”

To match the PR’s Tables terminology, prefer “Tables” when speaking about access control on rows.

Apply this diff:

- Appwrite Databases and Storage services can be configured to enforce access control rules. For example, you can restrict read and write access to rows by navigating to your database table settings in the Appwrite Console and setting the appropriate permissions.
+ Appwrite Tables and Storage services can be configured to enforce access control rules. For example, you can restrict read and write access to rows by navigating to your table settings in the Appwrite Console and setting the appropriate permissions.

---

138-138: Tighten phrasing on execute access

Minor clarity tweak and neutral wording re: SDKs.

Apply this diff:

- You can also configure **execute access** for your Appwrite functions, allowing you to specify who can execute the function using the client API.
+ You can also configure **execute access** for your Appwrite functions, allowing you to specify who can execute the function via function-level execute permissions (enforced for client SDK calls).

---

146-146: Grammar fix

Subject–verb agreement and smoother wording.

Apply this diff:

- But in addition to that, Appwrite also use encryption for storage.
+ In addition, Appwrite also uses encryption for storage.

src/routes/blog/post/what-is-golang/+page.markdoc (1)

12-12: Avoid time-relative phrasing; anchor to a version/date.

Suggest: “Appwrite announced support for the Go SDK and Functions runtime in Appwrite 1.6.” This keeps the post evergreen.

-Appwrite has just announced support for Go SDK and Function runtime in version 1.6.
+Appwrite announced support for the Go SDK and Functions runtime in Appwrite 1.6.

src/routes/blog/post/improve-devex-dev-keys/+page.markdoc (1)

94-94: Prefer Promise.allSettled for a demo expected to emit 429s.

Avoids a single rejection aborting the whole batch, while still logging failures.

-    await Promise.all(promises);
+    await Promise.allSettled(promises);

Rate limit on createRow is ~120 req/min for Client SDKs; many calls will reject with 429 in Step 2. (appwrite.io)

src/routes/blog/post/offline-first-journal/+page.markdoc (3)

59-64: Add a caution about permissive “Any” permissions.

Good for demos, unsafe for production. Suggest a short callout that production apps should restrict to authenticated users/roles.

---

159-159: Use RxDB’s own nomenclature (“collections”), not “tables,” to avoid confusion.

This sentence should say “create databases and collections.”

-The RxDB imports include core RxDB functionalities to create databases and tables and to add plugins,
+The RxDB imports include core RxDB functionalities to create databases and collections and to add plugins,

---

271-275: Optional: use Mango-style sort to avoid query-builder dependency.

You can do a full Mango query with sort instead of chaining. (rxdb.info)

-export const getJournals = async () => {
-  const db = await getDB();
-  return db.entries.find().sort({ updatedAt: 'desc' }).exec();
-};
+export const getJournals = async () => {
+  const db = await getDB();
+  return db.entries.find({ selector: {}, sort: [{ updatedAt: 'desc' }] }).exec();
+};

src/routes/blog/post/hacktoberfest-ideas-2024/+page.markdoc (1)

75-75: Grammar: make product/feature phrasing consistent

Use plural “Databases” and parenthetical “Tables” for clarity.

- - [Appwrite Database](https://appwrite.io/docs/products/databases) and Tables
+ - [Appwrite Databases](https://appwrite.io/docs/products/databases) (Tables)

src/routes/blog/post/scan-receipts-with-appwrite-functions/+page.markdoc (1)

275-276: Add a short example of persisting to a table

Since this section recommends storing results in a table (event-driven), add a quick snippet showing a createRow call with the server SDK to make it actionable.

src/routes/blog/post/everything-new-with-appwrite-1.5/+page.markdoc (1)

76-76: Terminology aligns; minor wording tweak for precision on contains

Consider clarifying “array element matching” to “membership testing” for array columns to better reflect semantics.

Apply this diff:

- - `contains` - partial text matches on string columns, array element matching on array columns
+ - `contains` - partial text matches on string columns; membership testing on array columns

src/routes/blog/post/product-update-june/+page.markdoc (2)

29-34: Bulleted items became plain paragraphs — confirm intent

Several lines lost the leading dash, changing list items into paragraphs. If that wasn’t intentional, restore the dashes to keep list styling.

Also applies to: 43-44, 55-56

---

71-71: Standardize terminology: collections → tables

Elsewhere we use tables/rows/columns. Update for consistency.

Apply this diff:

- - [Fix for migration of collections, columns and indexes of Databases](https://github.com/appwrite/appwrite/issues/8044)
+ - [Fix for migration of tables, columns, and indexes of Databases](https://github.com/appwrite/appwrite/issues/8044)

src/routes/blog/post/announcing-roles-for-enhanced-collaboration-and-security/+page.markdoc (1)

31-34: Replace relative dates with absolute dates for the promo window

“Until the end of the year” and “Starting in the new year” will go stale. Use concrete dates to avoid confusion.

Apply this diff with the actual dates:

- The new feature is now available on both the Pro and Scale plans. To celebrate the new feature, until the end of the year, you can invite members with the new roles to your Pro teams for free! This is the perfect opportunity to explore the new feature and see how it enhances your team's workflow.
- Starting in the new year, member seats will be priced at $15 per month as part of our standard pricing.
+ The new feature is now available on both the Pro and Scale plans. To celebrate the new feature, until December 31, 2024, you can invite members with the new roles to your Pro teams for free. This is the perfect opportunity to explore the new feature and see how it enhances your team's workflow.
+ Starting January 1, 2025, member seats will be priced at $15 per month as part of our standard pricing.

src/routes/blog/post/announcing-type-generation-feature/+page.markdoc (1)

24-30: Specify minimum CLI version: The appwrite pull tables command was introduced in Appwrite CLI v6.0.0. Update the snippet to require “Appwrite CLI v6.0.0+”.

src/routes/blog/post/introducing-new-database-operators/+page.markdoc (2)

26-32: Use Tables client and object-style params for listRows.

Recent Tables API examples use the Tables client and object params. Also align naming with tablesDB per our tutorials learning.

Based on your retrieved learnings for tutorials, consider:

-db.listRows(
-    '<DATABASE_ID>',
-    '<TABLE_ID>',
-	  [
-	    Query.contains('content', ['happy', 'love']),
-	  ]
-   )
+tablesDB.listRows({
+  databaseId: '<DATABASE_ID>',
+  tableId: '<TABLE_ID>',
+  queries: [
+    Query.contains('content', ['happy', 'love']),
+  ],
+})

Note: If this blog intentionally uses positional args, please confirm the SDK version this targets.

---

35-35: Clarify array-column phrasing.

"set a string column to act as an array" can confuse readers. Prefer "create a string[] column (array=true)".

-It’s important to note that the contains operator also works on array columns as well. For example, if we set a string column to act as an array, you could search this array in the same way you would search any other string.
+It’s important to note that the contains operator also works on array columns. For example, if you define a string[] column (array=true), you can search this array the same way as strings.

src/routes/blog/post/manage-user-permissions-with-labels-and-teams/+page.markdoc (1)

81-81: Capitalize brand and Console.

Minor polish.

-That's it for creating a Team and adding members from the appwrite console.
+That's it for creating a Team and adding members from the Appwrite Console.

src/routes/blog/post/announcing-go-support/+page.markdoc (2)

191-216: Storage example compiles, but keep imports tidy.

No issues; consider grouping imports, but optional.

---

219-219: Grammar nit.

"the ones the return" → "the ones that return".

-Some of our API endpoints such as the ones that return preferences from the Accounts and Teams APIs as well as the ones the return rows from the Appwrite Database are loosely typed...
+Some of our API endpoints—such as those that return preferences from the Accounts and Teams APIs, as well as those that return rows from the Appwrite Database—are loosely typed...

src/routes/blog/post/simplify-your-data-management-with-relationships/+page.markdoc (1)

50-51: Grammar: “a column” (not “an column”)

-...the reviews table will not have an column containing the related movie.
+...the reviews table will not have a column containing the related movie.

src/routes/blog/post/how-to-execute-database-migration-with-appwrite-cli/+page.markdoc (2)

61-63: Stale terminology (“collections”)

This section still references “collections”; the rest of the post uses “tables”.

-To make changes to your collections, edit the `appwrite.config.json` file.
+To make changes to your tables, edit the `appwrite.config.json` file.

---

95-104: Avoid storing phone numbers as integers

Phone numbers aren’t numeric (leading zeros, formatting, country codes). Prefer string.

   {
     "key": "phone",
-    "type": "integer",
+    "type": "string",
     "status": "available",
     "error": "",
     "required": false,
     "array": false,
-    "min": 1,
-    "max": 100,
+    "min": 1,
+    "max": 32,
     "default": null}

src/routes/blog/post/announcing-csv-imports/+page.markdoc (1)

25-25: Wording: avoid repetition (“row represents a row”)

-- Each subsequent row represents a row, with values separated by commas
+- Each subsequent line represents a data row, with values separated by commas

src/routes/blog/post/how-to-optimize-your-appwrite-project/+page.markdoc (2)

4-4: Typo in description (“yout” → “your”)

-description: Learn how to optimize your Appwrite project, manage resource usage, costs, and ensure smooth performance as yout application scales.
+description: Learn how to optimize your Appwrite project, manage resource usage, costs, and ensure smooth performance as your application scales.

---

249-249: Broken link scheme

Missing slashes in URL.

-- [Serverless functions 101: Best practices](http:appwrite.io/blog/post/serverless-functions-best-practices)
+- [Serverless functions 101: Best practices](https://appwrite.io/blog/post/serverless-functions-best-practices)

src/routes/blog/post/announcing-auto-increment-support/+page.markdoc (1)

40-40: Use “column” consistently (not “field”).

Terminology in this PR adopts “columns.” Align this sentence.

-For numeric ordering based on insertion order, you can use the `$sequence` field, which Appwrite automatically adds to all rows. This field increments with each new insert.
+For numeric ordering based on insertion order, you can use the `$sequence` column, which Appwrite automatically adds to all rows. This column increments with each new insert.

src/routes/blog/post/introducing-new-appwrite-cli/+page.markdoc (4)

12-12: Pluralize “table” → “tables.”

Reads better and matches service naming elsewhere.

-...apply changes to your Appwrite table.
+...apply changes to your Appwrite tables.

---

92-92: Use the correct service name in the command.

Standardize on appwrite push tables.

-When running `appwrite push table`, the CLI will compare...
+When running `appwrite push tables`, the CLI will compare...

---

108-113: Tighten grammar and code punctuation.

Move comma outside backticks and fix “read” → “recreated.”

-In this example, we can see that because we've renamed the column `times` to `time,` it will get deleted and read. We must also recreate the `timezone` column because we've changed its size from 256 to 255.
+In this example, because we've renamed the column `times` to `time`, it will be deleted and recreated. We must also recreate the `timezone` column because we've changed its size from 256 to 255.

---

120-121: Keep punctuation outside inline code.

Remove trailing comma and period from inside backticks.

-...such as `appwrite push tables,` to pre-answer all of them with `YES.`
+...such as `appwrite push tables`, to pre-answer all of them with `YES`.

src/routes/blog/post/introducing-functions-ecosystem/+page.markdoc (2)

67-76: “scheduledAt” is a parameter, not a column.

Adjust the comment to avoid DB terminology here.

-    invoiceDate.toISOString() // New scheduledAt column
+    invoiceDate.toISOString() // New scheduledAt parameter

---

119-121: Use “fields” instead of “columns” for Functions metadata.

Columns are DB-specific; executions/deployments have fields/attributes.

-You can now filter Function executions and deployments based on various columns, making it easier to monitor and debug your Functions:
+You can now filter Function executions and deployments based on various fields, making it easier to monitor and debug your Functions:

src/routes/blog/post/3-things-you-can-build-with-go-runtime/+page.markdoc (3)

202-204: Use “tableId” consistently instead of “collId” for clarity.

You’ve migrated to Tables/Rows, but variable names still say “collId”. Rename for consistency/readability.

-func DoesTableExist(dbs tablesdb.TablesDB, dbId string, collId string) bool {
-	_, err := dbs.GetTable(dbId, collId)
+func DoesTableExist(dbs tablesdb.TablesDB, dbId string, tableId string) bool {
+	_, err := dbs.GetTable(dbId, tableId)
@@
-func DoesColumnExist(dbs tablesdb.TablesDB, dbId string, collId string, attribId string) bool {
-	_, err := dbs.GetColumn(dbId, collId, attribId)
+func DoesColumnExist(dbs tablesdb.TablesDB, dbId string, tableId string, attribId string) bool {
+	_, err := dbs.GetColumn(dbId, tableId, attribId)
@@
-func InitialiseDatabase(Context openruntimes.Context, dbs tablesdb.TablesDB, dbId string, collId string) {
+func InitialiseDatabase(Context openruntimes.Context, dbs tablesdb.TablesDB, dbId string, tableId string) {
@@
-	doesCollExist := DoesTableExist(dbs, dbId, collId)
+	doesCollExist := DoesTableExist(dbs, dbId, tableId)
@@
-		dbs.CreateTable(
-			dbId,
-			collId,
+		dbs.CreateTable(
+			dbId,
+			tableId,
@@
-	doesAttribExist := DoesColumnExist(dbs, dbId, collId, "longUrl")
+	doesAttribExist := DoesColumnExist(dbs, dbId, tableId, "longUrl")
@@
-		dbs.CreateUrlColumn(
-			dbId,
-			collId,
+		dbs.CreateUrlColumn(
+			dbId,
+			tableId,
@@
-collId := "urlTable"
-services.InitialiseDatabase(Context, *tablesDB, dbId, collId)
+tableId := "urlTable"
+services.InitialiseDatabase(Context, *tablesDB, dbId, tableId)
@@
-row, err := tablesDB.GetRow(dbId, collId, shortId)
+row, err := tablesDB.GetRow(dbId, tableId, shortId)

Also applies to: 227-234, 237-246, 283-286, 329-338

---

218-248: Prefer passing a pointer to TablesDB to avoid copying and make the intent explicit.

Service methods likely have pointer receivers; passing by pointer avoids unnecessary copies and is idiomatic.

-func InitialiseDatabase(Context openruntimes.Context, dbs tablesdb.TablesDB, dbId string, tableId string) {
+func InitialiseDatabase(Context openruntimes.Context, dbs *tablesdb.TablesDB, dbId string, tableId string) {
@@
-services.InitialiseDatabase(Context, *tablesDB, dbId, tableId)
+services.InitialiseDatabase(Context, tablesDB, dbId, tableId)

Also applies to: 279-286

---

348-349: Tighten the scope list and fix punctuation.

Remove trailing comma; also verify whether both databases.* and {tables,columns,rows}.* are all required for this example.

-... `databases.read`, `databases.write`, `tables.read`, `tables.write`, `columns.read`, `columns.write`, `rows.read`, `rows.write`,
+... `databases.read`, `databases.write`, `tables.read`, `tables.write`, `columns.read`, `columns.write`, `rows.read`, `rows.write`.

Would you confirm the minimal scopes needed (especially if creating DB/table/column at runtime)?

src/routes/blog/post/announcing-atomic-numeric-operations/+page.markdoc (1)

89-96: Concurrency phrasing check.

“The row is locked during the update” — confirm this reflects the actual implementation (atomic server-side write vs. explicit row lock). Adjust wording if needed.

src/routes/blog/post/appwrite-realtime-for-flutter/+page.markdoc (2)

236-239: Subscribe to a scoped rows channel to reduce noise.

'rows' listens to all rows across all DBs/tables. Scope to your DB/table for fewer events and better perf.

-    subscription = realtime.subscribe([
-      'rows' // subscribe to all rows in every database and table
-    ]);
+    subscription = realtime.subscribe([
+      'databases.${database}.tables.${itemsTable}.rows' // only this table's rows
+    ]);

Please confirm the exact channel pattern for rows in the latest Flutter SDK docs.

Also applies to: 362-364

---

199-205: Minor terminology tweak (optional).

“Appwrite database service” → “Appwrite Tables service” to match TablesDB.

src/routes/blog/post/encrypted-attributes-for-sensitive-fields/+page.markdoc (3)

3-5: Align title/description terminology (“columns” vs “attributes”).

Description still mentions “encrypted string attributes.” Update to “columns” for consistency with the title/body.

 title: Secure sensitive database fields with encrypted string columns
-description: Learn how to use encrypted string attributes to protect sensitive data in your Appwrite database.
+description: Learn how to use encrypted string columns to protect sensitive data in your Appwrite database.

---

85-85: Grammar: “an column” → “a column”.

Quick copyedit.

-Once an column is marked as encrypted, that decision cannot be reversed.
+Once a column is marked as encrypted, that decision cannot be reversed.

---

94-94: Punctuation: add period.

Minor polish.

-If you are unsure, it is better to begin with unencrypted fields and migrate later once your needs are clearer
+If you are unsure, it is better to begin with unencrypted fields and migrate later once your needs are clearer.

src/routes/blog/post/track-document-order-with-sequence/+page.markdoc (1)

157-157: Wording: “id columns” → “id attributes”.

These are HTML attributes.

-This form captures the ticket title and description. Note the `id` columns on the form and inputs.
+This form captures the ticket title and description. Note the `id` attributes on the form and inputs.

src/routes/blog/post/ai-crystal-ball/+page.markdoc (1)

509-509: Remove stray ** in export.

Typo will break the code snippet.

-export const db = {**
+export const db = {

src/routes/blog/post/building-init-giveaway-app/+page.markdoc (1)

345-349: Optionally narrow Realtime to create events only.

Avoid reacting to updates/deletes by scoping to creation events.

-  return client.subscribe(
-    `databases.${DATABASE_NAME}.tables.${TABLE_NAME}.rows`,
+  return client.subscribe(
+    `databases.${DATABASE_NAME}.tables.${TABLE_NAME}.rows.*.create`,
     (response) => {
       // ...
     }
   );

src/routes/blog/post/build-personal-crm-sveltekit/+page.markdoc (1)

165-167: Remove unused imports.

ID and Query are not used in +server.js after the refactor.

-import { ID, Query } from 'node-appwrite';
+// import { Query } from 'node-appwrite';

src/routes/blog/post/best-pagination-technique/+page.markdoc (1)

48-51: Typo: add spacing around the “sum” column.

Minor readability fix.

-`sum`column
+`sum` column

src/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdoc (3)

75-77: Permissions and Row Security guidance: grammar + clarity nits.

• Line 92: lowercase “Open” → “open”.
• All good on enabling Row Security and table-level Create for Users; keep the screenshot step.

Apply:

- To ensure that users can only access their own expenses, Open the table's **Settings** tab ...
+ To ensure that users can only access their own expenses, open the table's **Settings** tab ...

Also applies to: 90-96

---

156-156: “column” → “attribute”

It’s an HTML attribute, not a column.

- The `data-sveltekit-preload-data="hover"` column enables ...
+ The `data-sveltekit-preload-data="hover"` attribute enables ...

---

281-283: Unused import (optional).

ID isn’t used in +page.svelte; import lives in the store. Safe to remove.

- import { ID } from 'appwrite'

src/routes/blog/post/understand-data-queries/+page.markdoc (2)

86-93: Use object-arg listRows and pass queries as an array.

Current call uses positional args and a single Query expression; TablesDB expects queries as an array, and examples should prefer the object-argument form. [Duplicate of earlier feedback, still present here.]

Apply:

-const movieData1 = tablesDB.listRows(
-    '[DATABASE_ID]',
-    '[TABLE_ID]',
-    Query.or([
-        Query.equal('title', ['Back To The Future', 'Top Gun']),
-        Query.greaterThan('year', 2017)
-	])
-);
+const movieData1 = await tablesDB.listRows({
+  databaseId: '[DATABASE_ID]',
+  tableId:    '[TABLE_ID]',
+  queries: [
+    Query.or([
+      Query.equal('title', ['Back To The Future', 'Top Gun']),
+      Query.greaterThan('year', 2017),
+    ]),
+  ],
+});

Queries are passed via the queries array, and logical operators nest sub-queries. (appwrite.io)

---

96-103: Same fix for AND example: object-arg + queries array.

Maintain parity with the OR example and SDK conventions. [Duplicate of earlier feedback.]

-const movieData2 = tablesDB.listRows(
-    '[DATABASE_ID]',
-    '[TABLE_ID]',
-    Query.and([
-        Query.startsWith("title", "Once"),
-        Query.greaterThan('year', 1995)
-	])
-);
+const movieData2 = await tablesDB.listRows({
+  databaseId: '[DATABASE_ID]',
+  tableId:    '[TABLE_ID]',
+  queries: [
+    Query.and([
+      Query.startsWith('title', 'Once'),
+      Query.greaterThan('year', 1995),
+    ]),
+  ],
+});

AND/OR group nested sub-queries, and queries must be an array passed to list endpoints. (appwrite.io)

src/routes/blog/post/understand-data-queries/+page.markdoc (2)

70-70: Nit: Prefer method-style naming.

Consider “listRows API” (camelCase) instead of “list rows API” for consistency with the SDK.

---

106-110: LGTM; aligns with object-arg form.

Optional: add await for consistency with the other examples.

-const movieData3 = tablesDB.listRows({
+const movieData3 = await tablesDB.listRows({
   databaseId: '[DATABASE_ID]',
   tableId: '[TABLE_ID]',
   queries: [Query.contains('director', ['Christopher Nolan'])],
 });

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: ebenezerdon
PR: appwrite/website#2372
File: src/routes/docs/tutorials/nuxt/step-6/+page.markdoc:79-83
Timestamp: 2025-09-05T19:35:04.162Z
Learning: In Nuxt tutorial files, the correct Appwrite database instance to use is `tablesDB` (imported from "~/appwrite"), not `database`. All tablesDB method calls should use the object parameter format: listRows({ databaseId, tableId, queries }), createRow({ databaseId, tableId, rowId, data }), and deleteRow({ databaseId, tableId, rowId }).

Learnt from: ebenezerdon
PR: appwrite/website#2372
File: src/routes/docs/tutorials/react/step-6/+page.markdoc:70-75
Timestamp: 2025-09-05T19:35:53.943Z
Learning: In React tutorial files, the correct Appwrite database instance to import is `tablesDB` from "../appwrite", not `databases`. The import statement should be `import { tablesDB } from "../appwrite"` to match the usage throughout the React tutorial code.

Learnt from: ebenezerdon
PR: appwrite/website#2372
File: src/routes/docs/tutorials/react-native/step-6/+page.markdoc:67-73
Timestamp: 2025-09-05T19:35:59.449Z
Learning: In React Native tutorials, the lib/appwrite.js file exports `tablesDB` (not `databases`), so imports should use `import { tablesDB } from "../lib/appwrite"` to match the export pattern established in step-3.

Learnt from: ebenezerdon
PR: appwrite/website#2372
File: src/routes/docs/tutorials/react-native/step-6/+page.markdoc:67-73
Timestamp: 2025-09-05T19:35:59.449Z
Learning: In React Native tutorials, the lib/appwrite.js file exports `tablesDB` (not `databases`), so imports should use `import { tablesDB } from "../lib/appwrite"` to match the export pattern established in step-3.

Learnt from: ebenezerdon
PR: appwrite/website#2372
File: src/routes/docs/tutorials/nuxt/step-6/+page.markdoc:79-83
Timestamp: 2025-09-05T19:35:04.162Z
Learning: In Nuxt tutorial files, the correct Appwrite database instance to use is `tablesDB` (imported from "~/appwrite"), not `database`. All tablesDB method calls should use the object parameter format: listRows({ databaseId, tableId, queries }), createRow({ databaseId, tableId, rowId, data }), and deleteRow({ databaseId, tableId, rowId }).

src/routes/blog/post/improve-devex-dev-keys/+page.markdoc (3)

30-30: Version requirement and CORS setup need updates (see previous comments).

The existing review comment correctly identifies that TablesDB requires Appwrite 1.8+ and that a Web platform configuration step should be added to avoid CORS errors.

---

84-89: createRow should use object-parameter syntax (see previous comment).

The existing review comment correctly identifies that the positional argument syntax is deprecated. Based on learnings from tutorial files, the correct pattern is createRow({ databaseId, tableId, rowId, data }).

---

98-98: Terminology updated, but error explanation needs clarification (see previous comment).

The "rows" terminology is correct. However, the existing review comment correctly identifies that the explanation should distinguish between CORS errors (when no Web platform is configured) and 429 rate limit errors.

src/routes/blog/post/how-to-optimize-your-appwrite-project/+page.markdoc (2)

30-34: Use object-argument form for listRows consistency.

This code example uses positional arguments, which is inconsistent with the SDK usage pattern. Based on learnings, tablesDB methods should use object parameter format.

This issue was already flagged in a previous review comment.

---

46-54: Use object-argument form for listRows.

The pagination example uses positional arguments, which is inconsistent with the SDK usage pattern established elsewhere in the codebase.

Based on learnings

Apply this diff to use the object-argument form:

-const firstPage = await tablesDB.listRows(
-  '<DATABASE_ID>',
-  '<TABLE_ID>',
-  [
-    Query.equal('author', 'Meredith Palmer'),
-    Query.limit(20),
-    Query.offset(0),// Fetch the first 20 records
-  ]
-})
+const firstPage = await tablesDB.listRows({
+  databaseId: '<DATABASE_ID>',
+  tableId: '<TABLE_ID>',
+  queries: [
+    Query.equal('author', ['Meredith Palmer']),
+    Query.limit(20),
+    Query.offset(0), // Fetch the first 20 records
+  ]
+});

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react/step-6/+page.markdoc:70-75
Timestamp: 2025-09-05T19:35:53.943Z
Learning: In React tutorial files, the correct Appwrite database instance to import is `tablesDB` from "../appwrite", not `databases`. The import statement should be `import { tablesDB } from "../appwrite"` to match the usage throughout the React tutorial code.

Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react-native/step-6/+page.markdoc:67-73
Timestamp: 2025-09-05T19:35:59.449Z
Learning: In React Native tutorials, the lib/appwrite.js file exports `tablesDB` (not `databases`), so imports should use `import { tablesDB } from "../lib/appwrite"` to match the export pattern established in step-3.

Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react-native/step-6/+page.markdoc:67-73
Timestamp: 2025-09-05T19:35:59.449Z
Learning: In React Native tutorials, the lib/appwrite.js file exports `tablesDB` (not `databases`), so imports should use `import { tablesDB } from "../lib/appwrite"` to match the export pattern established in step-3.

Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/nuxt/step-6/+page.markdoc:79-83
Timestamp: 2025-09-05T19:35:04.162Z
Learning: In Nuxt tutorial files, the correct Appwrite database instance to use is `tablesDB` (imported from "~/appwrite"), not `database`. All tablesDB method calls should use the object parameter format: listRows({ databaseId, tableId, queries }), createRow({ databaseId, tableId, rowId, data }), and deleteRow({ databaseId, tableId, rowId }).

Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/nuxt/step-6/+page.markdoc:79-83
Timestamp: 2025-09-05T19:35:04.162Z
Learning: In Nuxt tutorial files, the correct Appwrite database instance to use is `tablesDB` (imported from "~/appwrite"), not `database`. All tablesDB method calls should use the object parameter format: listRows({ databaseId, tableId, queries }), createRow({ databaseId, tableId, rowId, data }), and deleteRow({ databaseId, tableId, rowId }).

Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react/step-6/+page.markdoc:70-75
Timestamp: 2025-09-05T19:35:53.943Z
Learning: In React tutorial files, the correct Appwrite database instance to import is `tablesDB` from "../appwrite", not `databases`. The import statement should be `import { tablesDB } from "../appwrite"` to match the usage throughout the React tutorial code.

Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react-native/step-6/+page.markdoc:67-73
Timestamp: 2025-09-05T19:35:59.449Z
Learning: In React Native tutorials, the lib/appwrite.js file exports `tablesDB` (not `databases`), so imports should use `import { tablesDB } from "../lib/appwrite"` to match the export pattern established in step-3.

Learnt from: stnguyen90
Repo: appwrite/website PR: 2520
File: src/routes/docs/advanced/self-hosting/production/updates/+page.markdoc:13-15
Timestamp: 2025-10-24T22:17:14.669Z
Learning: In Appwrite versioning, RC (Release Candidate) versions like `1.6.2-RC1` come before the stable release `1.6.2`. Documentation should recommend upgrading to stable versions, not RC versions.

Learnt from: BretRen
Repo: appwrite/website PR: 2442
File: src/routes/docs/products/auth/email-password/+page.markdoc:22-31
Timestamp: 2025-09-25T05:26:19.287Z
Learning: Appwrite JavaScript SDKs now support object-based arguments instead of positional arguments as of 2025. The account.create method should be called with an object parameter containing userId, email, password, and optional name, rather than positional arguments. Positional arguments still work but are deprecated.

Learnt from: BretRen
Repo: appwrite/website PR: 2442
File: src/routes/docs/products/auth/email-password/+page.markdoc:50-56
Timestamp: 2025-09-25T05:24:12.551Z
Learning: Appwrite v17+ uses object parameters consistently across Account methods. Both account.create({ userId, email, password }) and account.createEmailPasswordSession({ email, password }) use object parameters instead of positional arguments.